Dave, Sumandra,

I made the following change in Section 4.10.5., paragraph 7:

OLD:

    The matching criteria for SFF can be more sophisticated.  For
    example, the matching criteria could be any fields in the data
    packets, such as (non-exhaustive list):

NEW:

    The matching criteria for SFF can be more sophisticated.  For
    example, it could be the SFP-id together with any fields in the data
    packets, such as (non-exhaustive list):

Better?

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Sumandra Majee
Envoyé : jeudi 28 avril 2016 21:03
À : Dave Dolson; sfc@ietf.org
Cc : Jim Guichard (jguichar)
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Dave,
I would also concur that SFF is a forwarding entity that uses pathID/SI to find the next-hop/next-sf/next-sff. This is how our SFF works.

It is absolutely possible that co resident classifier to further classify based on  l3/l4/l7/python_code and change the path. But logically that is another classification and list below is certainly not exhaustive.

From: sfc <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org>> on behalf of Dave Dolson <ddolson@sandvine.com<mailto:ddolson@sandvine.com>>
Date: Thursday, April 28, 2016 at 11:43 AM
To: "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Cc: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.com>>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Further to Jim's points about section 4.10.5, do I read it correctly that the SFF can be configured to steer traffic on the basis of these?
   o  Destination MAC address
   o  Source MAC address
   o  VLAN-ID,
   o  Destination IP address
   o  Source IP address
   o  Source port number
   o  Destination port number
   o  DSCP
   o  Packet size, etc., or any combination thereof.

This comes totally unexpected to me, thinking that the SFF steers traffic based exclusively on Service Path Identifier and Service Index (SPI/SI), which oddly aren't in the above list.

I can guess that maybe this is about reclassification, but "classification" isn't mentioned in 4.10.5.
Can someone explain?

-Dave



From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Martin & WG:

A few comments that I would like to see addressed in the document before it can move forward to the next step.

  *   Section 2.2 SFC Control Plane Bootstrapping.
This section is too wishy washy. It makes the statement "this document assumes the SFC control plane is provided with a set of information that is required for proper SFC operation" but then goes on to list bullets that are likely to be provided or may be provided. It does not actually provide any information on what is required for proper SFC operation. In the list of likely information there is no indication of whether this information must exist in the network prior to bootstrapping the SFC control plane element; this is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actually function although it is reasonable to assume that it can bootstrap without any information (albeit it can't actually do anything). On this point I would argue that several of the may elements are actually required such as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the SFC control plane element, or may be added later through some control interface.

Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy

  *   Section 2.3 Coherent Setup of an SFC-enabled Domain
What does the sentence "various transport encapsulation schemes and/or variations of SFC header implementations may be supported" actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or something else ? Note that there is only one SFC header implementation based on the WG charter so if we are referring to different SFC formats (meaning metadata) then please make this clear in the text, and if not, please remove this sentence.

  *   Section 3.1 Reference Architecture
Second bullet point "mapping between service function chains and SFPs" - this is a general comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only once in the entire document. The architecture is explicit in that the SFP when rendered into the network is an RSP and therefore the SFC control plane element needs to have information on currently deployed RSPs.

Additionally there is no interface specified for communication between the SFC Control Plane Element and SF management systems. This is an important aspect as many SF's may require that SFC information be communicated to their management systems that will be responsible for communicating directly with their respective SF's.

  *   Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifier
The sentence "The control plane may instruct the classifier about the initial values of the Service Index (SI)" should be changed to say MUST as otherwise if a classifier chooses whatever value it wants then that may not align with what is programmed into the SFFs by the SFC Control Plane element.

  *   Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets
This section does not actually provide any meaning or indication of relationship with the SFC Control Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire section should be removed from the document.

  *   Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP
Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #1. Is this simply a typo or are you trying to convey something else ?

Further you state that "the steering policies to a SFF node for service function chain depends on if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific" -  this is an inaccurate statement as the combination of the SFP-id and service-index determines the forwarding behavior (as specified in section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

Jim



On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org> on behalf of mls.ietf@gmail.com<mailto:mls.ietf@gmail.com>> wrote:

Dear all,

This is the start of the Working Group Last Call (WGLC) for

draft-ietf-sfc-control-plane-04.txt

The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT.

Please send your comments and reviews to the sfc@ietf.org<mailto:sfc@ietf.org> list.

Regards,

   Martin (SFC co-chair)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc